Subject: Re: Preliminary SIG agenda

From: "jim (j.) cobban" <[email-masked]>
Date: Thu, 24 Oct 1996 13:07:00 -0400

In message "Re: Preliminary SIG agenda", Brian Jewell writes:

>Ralph,
>
>Re: the Agenda...
>
>> 
>> MAPPING LU AND PU NAMES BETWEEN VTAM AND TYPE 2.0 NODES
>> 
>> There is a proposal to add a new system definition parameter to VTAM to allow
>> LU and PU names to be sent to DLUR-attached devices.
>> 
>> 
>
>This issue was first raised a while ago and I've forgotten some of the
>specifics about what was proposed. But I do think the scope of it went
>beyond just dealing with the problem for DLURs. The original intent was
>to provide a means for passing PU/LU names in traditional SNA networks,
>as well.

VTAM already passes the LU and PU names to DLUR, as it does to the NCP
Boundary Function.  The problem is that both DLUR and the NCP Boundary
Function delete the names from ACTLU and ACTPU before forwarding them to the
end device, because some idiot might have written a PU2 that will choke if it
receives these vectors.  Therefore both DLUR and NCP BF need to know
explicitly whether it is OK to leave the CV0E on these requests.  It is
desireable that both DLUR and NCP BF perform this function in exactly the
same way and while the behavior of DLUR is under our collective control, NCP
BF remains the property of IBM (and they are welcome to it!).  As the
implementors of equipment which is attached to IBM NCPs it is important that
IBM enhance the NCP in step with DLUR, however the AIW as an organization
cannot demand any modification of the NCP.  However each of us, along with
our customers, who are in turn customers of IBM, can request this
functionality.  IBM naturally will perform a market evaluation and decide
whether to deploy the functionality in 3746/DLUR or 3745/NCP BF or both.

Since VTAM is the one piece of code which is common to both configurations,
and since one of the most popular implementation options in DLUR is to have all
of the configuration information shipped down from VTAM, it can be argued
that having a configuration parameter, whose value is signalled explicitly to
both DLUR and NCP BF, is a reasonable option.  We were unable to agree on the
feasability of any other more dynamic solution.